Application programming interfaces (APIs) are used by developers to create a wide variety of applications and programs. Developers range from office workers recording macros to low-level device driver authors. These developers rely on different languages and/or different frameworks of differing complexities while programming with different skill sets and/or for different purposes. Traditionally, different APIs have been designed to target different individual levels of skill and different demands for control (e.g., based on different relevant scenarios).
Although this approach can be successful in providing APIs that are optimized for a specific developer, it has significant drawbacks. For example, the multiple framework approach creates situations where developers have difficulty transferring knowledge from one skill level and scenario type to another. When there is a need for them to implement a scenario using a different framework, developers hit a very steep learning curve. And not only is the learning curve very steep, but it generally requires that the code written to a first lower-skill-level framework has to be rewritten from scratch to a second higher-skill-level framework. Moreover, the creation of separate frameworks for different developer skill levels typically results in a situation in which APIs that are targeted for or implemented by one level of developer are unusable by another level of developer.
FIG. 1 illustrates a graph 101 of a traditional API learning curve with regard to two different frameworks. The first framework corresponds to a framework that has a relatively lower level of required skills and/or difficulty and a concomitantly relatively lower capacity for control by a developer. The second framework, on the other hand, corresponds to a framework that has a relatively higher level of required skills and/or difficulty and a concomitantly relatively higher capacity for control by a developer. Such a first framework might be used by a novice or infrequent developer, and such a second framework might be used by an experienced or professional developer. For example, the first framework may correspond to one designed for Visual Basic, and the second framework may correspond to one designed for C++.
In this traditional approach, relatively separate and disparate APIs are designed and employed as part of each framework. A steep but relatively short learning curve is traversed to enable API usage for the first framework at the relatively lower skill level and control capability. Because of the separate and disparate nature of the two API frameworks, the experience with the first framework contributes little if any knowledge toward learning the second API of the second framework. Consequently, an equally steep but even taller learning curve is traversed to enable API usage for the second framework.
In other words, learning an API of the first framework does not provide a stepping stone to learning an API of the second framework. The regressive nature of this disjointed set of API frameworks is indicated by the continuity gap. A developer who has learned the API of the first framework is no closer to learning the API of the second framework and must therefore start with the basics of the second framework.
Another problem with traditional frameworks is that they tend to have an overall poor usability in any case. In general, object oriented design/development (OOD) methodologies (e.g. unified modeling language (UML)) are “optimized” for maintainability of the resulting design and not for usability of the resulting frameworks. OOD methodologies are better suited for internal architecture designs and less suited for designs of an API layer of a large reusable library. For example, poor usability can result from OOD methodologies that focus only on distillation to a lowest fundamental block and/or that have an unwavering allegiance to a strict inheritance hierarchy throughout an API design.
Accordingly, there is a need for schemes and/or techniques that can at least ameliorate the regressive continuity gap of a traditional API learning curve and/or that can deliver better overall API usability.